% This example An LaTeX document showing how to use the l3proj class to
% write your report. Use pdflatex and bibtex to process the file, creating 
% a PDF file as output (there is no need to use dvips when using pdflatex).

% Modified 

\documentclass{l3proj}
% The following is needed in order to make the code compatible
% with both latex/dvips and pdflatex.
\ifx\pdftexversion\undefined
\usepackage[dvips]{graphicx}
\else
\usepackage[pdftex]{graphicx}
\DeclareGraphicsRule{*}{mps}{*}{}
\fi
\usepackage{alltt} 
\usepackage{hyperref}
\makeatletter
\newcommand\ackname{Acknowledgements}
\if@titlepage
  \newenvironment{acknowledgements}{%
      \titlepage
      \null\vfil
      \@beginparpenalty\@lowpenalty
      \begin{center}%
        \bfseries \ackname
        \@endparpenalty\@M
      \end{center}}%
     {\par\vfil\null\endtitlepage}
\else
  \newenvironment{acknowledgements}{%
      \if@twocolumn
        \section*{\abstractname}%
      \else
        \small
        \begin{center}%
          {\bfseries \ackname\vspace{-.5em}\vspace{\z@}}%
        \end{center}%
        \quotation
      \fi}
      {\if@twocolumn\else\endquotation\fi}
\fi
\makeatother

\begin{document}
\title{``Just Another Messenger'' -- JAM}
\author{Daniel Callander \\
        Agnieszka Kielbinska \\
        Stephen McQuistin \\
        David Newall \\
        Ian Scott}
\date{19-03-2012}
\maketitle
\begin{abstract}

JAM is an instant messaging system, consisting of a client and server, which communicate using a protocol which we have designed. This dissertation describe the stages of requirements gathering, design, implementation and testing which led to the specification of our protocol, and our client and server software. It describes the problems which we encountered in each of these stages, and detail how these problems were handled.
\end{abstract}
\begin{acknowledgements}
  We would like to thank our team supervisor, Colin Perkins, for his guidance and feedback. In addition, our thanks go to Tim Storer for his feedback during our demonstration, and for providing points for critical reflection.

The logo and artwork was produced by Kirsty Whitaker, and we thank her for giving up her spare time to help us with this.
\end{acknowledgements}
\tableofcontents
%==============================================================================
\chapter{Introduction}
\label{intro}
\input{sections/introduction}

%==============================================================================
\chapter{Requirements}
\label{req}
This chapter consists of the problem proposal provided to our team, along with our analysis and interpretation of this proposal. This interpretation is then formalised into a prioritised list of specific features.

\section{Problem definition \& analysis}
\input{sections/requirements_problem}

\section{Features}
\input{sections/requirements_features}

\section{Summary}
\input{sections/requirements_summary}

%==============================================================================
\chapter{System Architecture}
\label{req}
This chapter describes the overall architecture of the system, as well as discussion of how this architecture was selected over the alternatives.

\section{Choosing an architecture}
\input{sections/sysarch_csp2p}

\section{Summary}
\input{sections/sysarch_summary}

%==============================================================================
\chapter{Protocol}
\label{protocol}
The design of the protocol was one of the most important parts of the project as it heavily affected the design of the rest of the system. The protocol defines the format in which the clients and server communicate; any client program wishing to communicate with a JAM server must follow the rules of this protocol consistently. By defining a protocol, this also means that the server need not worry about a particular client's implementation -- as long as their messages follow the protocol specification.

At its most basic view, the JAM protocol operates in a very simple manner. A client connects to the server and they then exchange messages until the connection is closed. Any number of clients can be connected to the server and exchanging messages at a time. 

The following sections will deal with the syntax (the grammar and format) and semantics (the underlying meaning) of the protocol.
\section{Syntax}
\input{sections/protocol_syntax}
\section{Semantics}
\input{sections/protocol_semantics}
\section{Error Handling}
\input{sections/protocol_error}
\section{Interaction}
\input{sections/protocol_interaction}
\section{Channels}
\input{sections/protocol_channels}
\section{Evolution}
\input{sections/protocol_evolution}

%==============================================================================
\chapter{Client}
\label{client}
This chapter will discuss the design, implementation and evaluation of the client. Every user of our system will run and interact with the JAM client. It is a completely separate program from the server, as described in chapter 3. The chapter begins with discussion of the client architecture, which explains and justifies our design choices. Following this, we discuss the implementation choices and issues as part of the architecture review. We then describe how we arrived at the design of GUI for the client, and discuss the problems which resulted from implementing this design. We finish by outlining the known issues of the client implementation, and then by detailing our client evaluation.
\section{Architecture Design}
\input{sections/client_archdesign}
\section{Architecture Review}
\input{sections/client_archimpl}
\section{GUI Design}
\input{sections/client_guidesign}
\section{GUI Implementation}
\input{sections/client_guiimpl}
\section{Evaluation}
\input{sections/client_eval}
\section{Summary}
\input{sections/client_summary}

%==============================================================================
\chapter{Server}
In this chapter we shall discuss the design decisions made for the server architecture, as well as how this architecture was implemented. Following this shall be a section detailing how we evaluated the server along with what we learned through the process and, as a reflective exercise, what we would do differently if given the opportunity.
\label{server}

\section{Design}
\input{sections/server_design}
\section{Implementation}
\input{sections/server_impl}
\section{Evaluation}
\input{sections/server_eval}

%==============================================================================
\chapter{Integration Testing}
The fundamental principle of the system is that we have a client and server which interact using a specified protocol. While the client and server have been evaluated independently, this chapter outlines the strategy, and the results, of testing these two components together.
\label{integrationtest}
\section{Strategy}
\input{sections/eval_strat}
\section{Results}
\input{sections/integ_eval}
\section{Summary}
\input{sections/integ_summary}
%==============================================================================
\chapter{Conclusion}

\input{sections/conclusion_reflection}

%==============================================================================
\bibliographystyle{plain}
\bibliography{example}

\appendix
\chapter{Protocol Specification}
\input{sections/appendix_protospec}
\chapter{Organisation \& Scheduling}
\input{sections/appendix_orgsched}
\chapter{Contributions}
\input{sections/appendix_contrib}
\chapter{Test Scripts}
\input{sections/appendix_testing}
\end{document}
